This invention relates to workflow access protocols as used in process management software tools.
Workflow systems monitor and control activities occurring over an extended period of time and quite possibly over extended distances. It is quite common for such workflow systems to require communication and coordination between more than one computer.
Many previous workflow systems have been built with proprietary tools, including proprietary communication protocols between the interacting computers of the system. While such systems have been able to perform important tasks, there have been substantial problems associated with such systems. Proprietary protocols pose significant difficulties for integration of multiple-vendor tools. Most of these proprietary protocols require specific client viewing/interaction tools for users to access such workflow systems. Proprietary protocols require a separate, often substantial effort to integrate into enterprise class infrastructure environments, such as CORBA.
The OMG (Object Management Group) consortium has sought to provide a standardized workflow access protocol compatible with CORBA (Common Object Request Broker Architecture). While this systems approach has some significant advantages, it has one substantial limitation. The CORBA infrastructure is limited to operation within an enterprise computer environment. CORBA does not reasonably traverse firewalls. As such this approach does not readily support workflow situations which must traverse one or more firewalls, as is the situation in extranet applications, among many others.
The OMG consortium has provided an HTTP-compliant protocol, known as IIOP (Internet Inter-ORB), allowing CORBA based applications to communicate with other CORBA applications in different enterprises. This complex, sophisticated protocol requires a significant development investment to interface smaller applications to such engines. Small business software such as inventory control and purchase tracking systems would suffer a significant expense with such a protocol.
There is an additional problem in these above discussed protocols. Each of them typically requires the invocation of multiple methods of the object class to return the complete state of the workflow object instance. This is not only inefficient, but also leaves open the possibility of the process state changing between retrieval of different parts of the process object instance. What is needed is a protocol retrieving the workflow object-state in its entirety as one operation.
Workflow access protocols such as Simple Mail Transport Protocol (SMTP) can traverse firewalls based upon using email as an access protocol. While such systems can address some of the requirements of workflow beyond one enterprise, the use of email based protocols poses other problems. Email is a non-synchronous communication protocol, which propagates messages by a store and forward procedure. Process management requires synchronization. While techniques to provide synchronization have been built on top of email, these techniques have been very clumsy and unnatural. Such techniques also suffer significant overhead in terms of system response delay, which limits the kinds of workflow applications that can be monitored and controlled.
What is needed is a simple, synchronous access protocol capable of traversing firewalls possessing an infrastructure upward compatible to the OMG workflow protocol supporting CORBA, capable of retrieving the entire state of a workflow object as a single operation.
One aspect of the invention provides an HTTP based extensible protocol supporting a subset of the workflow object names and definitions of the OMG workflow protocol. HTTP is a synchronous communication interface. The HTTP based protocol can communicate across the Internet, traversing firewalls. Workflow applications requiring such traversal could then be built and readily integrated into the enterprise side workflow systems built with the OMG workflow protocol and CORBA.
A further embodiment of the invention incorporates the following objects: An instance of a ProcessDefinition object exists for every process definition input into the system. Its primary function is to create particular process instances (called WorkProcess instances). A WorkProcess represents an instance of a particular process. It will typically be given a unique process instance ID, which is used as part of the URL. The WorkProcess is a way to access the overall process state and to control it at some level. A WorkProcess instance may additionally have active references to WorkActivity instances, which portray which external activities the process is waiting on. A WorkProcess instance may additionally have one or more references to WorkRequester objects to be posted when the current WorkProcess is completed. WorkActivity instances provide a description of the activity being waited on, who is assigned to the activity, and if automated, give a reference to the performer of the activity. A WorkRequester instance is the context object for those WorkProcesses started by some other long-term object. The WorkProcess object can provide the context data for the Workprocess and represents the required object to be informed when the process instance completes.
A further embodiment of the invention incorporates at least one ProcessDirectory object, which is used to search and find ProcessDefinition objects.
A further embodiment of the invention incorporates a directory server which stores, accesses and updates the instances of the above workflow objects as well as the above workflow object definitions. The directory server is URL accessible via HTTP protocols, with each workflow object instance possessing a unique URL incorporating a single URL base address.
A further embodiment uses the LDAP protocols of the Netscape directory server to further facilitate the support of HTTP. Use of LDAP as a storage repository of object definitions supports local replication of object definitions. LDAP directory servers further replicate data, providing an easy way to distribute process definitions and changes to process definitions across large enterprise systems.
A further embodiment of the invention integrates into the HTTP based extensible protocol with the directory server a standardized data encapsulation protocol supporting tag names and data contents for object definitions. The tag names and data contents are upward compatible with the OMG workflow object names and definitions. This is advantageous by allowing straightforward use by many systems tools already supporting the data encapsulation mechanism and further aiding the support of integration of workflow application systems with both internal and external processes and activities. A further embodiment of the invention uses the XML standard for data encapsulation in communication with other workflow engines.
These and other advantages of the present invention will become apparent upon reading the following detailed descriptions and studying the various figures of the drawings.